fix(checkpoints): snapshot the task/session cwd before destructive terminal commands - #70230

Problem

The checkpoint taken before a destructive terminal command resolves its directory as:

cwd = function_args.get("workdir") or os.getenv("TERMINAL_CWD", os.getcwd())

But the terminal tool itself executes the command in the task/session cwd (explicit workdir → per-task override → live session cwd → TERMINAL_CWD/process cwd — see terminal_tool's resolution). Any session created with an explicit cwd (session.create(cwd=...)) or re-anchored via session.cwd.set runs its commands in a directory that can differ from the Hermes process cwd.

Consequence: for those sessions, the pre-destructive-command checkpoint snapshots the wrong tree (the process cwd), and a later rollback silently restores nothing of what the rm/git reset/etc. actually touched.

_ensure_file_checkpoint was already fixed to honor the task cwd in #68195 — this is the terminal twin of that fix.

Fix

New _terminal_checkpoint_cwd(function_args, effective_task_id) helper that mirrors the file-tools resolution (_resolve_path_for_task(".", task_id) — same base-dir pipeline), used by both the batch and sequential call-sites. Explicit workdir still wins; without a session override, behavior is unchanged (TERMINAL_CWD → process cwd).

Tests

tests/agent/test_terminal_checkpoint_cwd.py:

• explicit workdir wins,
• a per-task cwd override beats process cwd and a stale TERMINAL_CWD (the regression),
• without an override the historical TERMINAL_CWD fallback is preserved.

Found while integrating a downstream client that re-anchors sessions per workspace via session.cwd.set — file-tool checkpoints landed in the right tree, terminal ones didn't.

🤖 Generated with Claude Code

https://claude.ai/code/session_017PkWV7rR2oeg8BBttcNoyE